There are already existing methods of fare collection implemented by public transit service providers or the like. The fares are collected by fare payment terminals hereafter called “validation terminals,” installed at entry gates, exit gates or within service zones. These terminals calculate fare payments and validate the customer's access to services.
Payment instruments applied in these systems are customer-held portable devices hereafter called “cards.” Examples include smartcards, contactless cards, cellular phones, personal digital assistants and transponders. Fare collection transactions are originated by the cards at validation terminals.
The cards can be issued by worldwide or regional financial payment infrastructure, including but not limited to Visa International or MasterCard Worldwide, hereafter called “payment associations.” The cards issued by payment associations are commonly called “open-loop cards.” The open-loop cards do not normally store customer related and transaction related data supporting the validation and fare calculation logic. Examples of public transit-specific data not normally stored in the open-loop cards are: preauthorized or prepaid service balance, previous validation activity originated by a card, customer privilege or concession class (‘senior’; ‘student; etc.) and loyalty parameters specific to a given transit system.
There are also so-called “closed-loop cards” that are used specifically for fare collection. These cards are not issued by payment associations, generally may not be used in the broader market payment infrastructure but are generally restricted to the specific fare collection system for which they are issued.
There are also hybrid fare collection systems comprising both types of cards: open-loop and closed-loop, as well as hybrid payment instruments comprising both types of cards.
Open-loop fare collection systems have certain advantages. For example, customers already having open-loop cards do not need to acquire additional, closed-loop cards and replenish them with funds before they start using a transit system.
The typical public transit fare collection process comprises at least some of the following types of validation transactions executed at validation terminals and originated by cards: “check-in,” “check-out,” “transfer” and “inspection.”
The check-in transaction is typically originated when a customer presents the card to a validation terminal at the beginning of a trip, for example, at the entry gate to a subway station or when boarding a bus or train.
The check-out transaction is typically originated when a customer presents the card to a validation terminal at the end of a trip. Check-out transactions are commonly used by transit systems where the fare depends on the distance traveled (so called distance-based or zone-based fare systems).
The transfer transaction is typically originated when a customer transfers from one route to another, one vehicle to another or one transit entity to another transit entity participating in the same fare collection system. A transfer transaction may sometimes be a variation of a check-in transaction or complementary to a check-in transaction.
An inspection transaction may be implemented in some transit systems to verify the validity of a combination of a fare and trip. An inspection transaction is typically originated when a card is presented to an inspection validation terminal that may be carried by fare-enforcement staff during any phase of a trip.
Card-specific data created or modified during validation transactions is hereafter called “card activity data.” Newly created card activity data may be required later, at the succeeding transactions originated by the same card. For example, the check-out fare may depend on a check-in location, the transfer fare may depend on a previous check-in or check-out location or a fare discount may depend on a previous validation transaction. Open-loop cards do not normally store card activity data whereas closed-loop cards usually do.
Open-loop cards, closed-loop cards and fare collection systems using them are well known. An example could be the Oyster card system that has been in use by Transit for London in UK for many years. Initially it was a closed-loop card system. Recently this system started migration to open-loop cards.
A known embodiment of the closed-loop card system is presented in U.S. Pat. No. 6,732,922, by Robert Lindgren et al. In Lindgren, the invention comprises a method of prepaying services i.e. loading the closed-loop card with funds via the Internet before the card can be used in the system. The validation terminals, connected permanently to the service provider's central host, will learn about this load event in a relatively short period of time, but it usually requires significantly more time before this information reaches vehicle-based validation terminals.
A known embodiment of the open-loop card system is presented in U.S. Pat. No. 7,567,920, “On-line authorization in access environment” by Ayman Hammad et al. Hammad introduces a method of registering an open-loop card with a transit system before it can be used at the system's validation terminals. The registration serves the purpose of pre-paying or pre-authorizing a certain amount of funds by means of a regular payment card transaction. The registration also gives an opportunity to authenticate the card and the customer during a relatively lengthy transaction at the registration point of sale. The data associated with the card and the registration transaction is stored in a service provider's central host, so validation terminals connected to this host can validate access to the system and collect the fare fast enough. The validation transaction will require only 0.3-0.5 s, considered to be an upper limit for the validation process duration, whereas the registration transaction may take up to 10 seconds to receive the card issuer authorization.
The aforementioned U.S. Pat. No. 7,567,920 also assumes that while the customer walks from the registration terminal to the validation terminal there is enough time to obtain the card issuer's authorization.
In many known solutions, the service provider's central host stores data describing the card and the customer. This data may include, for example, a positive card list with pre-authorized balances, customer privileges, and discount parameters. The validation terminals execute validation transactions in online mode, being connected to the central host that stores validation support data.
For the purpose of this disclosure, the data pertinent to the card, the customer, and the registration transaction is hereafter called “registration data.” The data pertinent to the card usage and fare collection transactions is hereafter called “card activity data.” The registration data together with the card activity data is hereafter called “validation support data.” The data, other than validation support data, that needs to be propagated to validation terminals in a fare collection system is called hereafter “other terminal data.” It may include, for example, a negative lists, fund loading lists, system topology data, route schedules and fare pricelists.
Another example of a system with a registration transaction is presented in the U.S. Pat. No. 7,568,617, “Learning fare collection system for mass transit”, by Martin Friedrich Ludwig Silbernagl et al. The method presented in this patent also comprises an open-loop card registration and storing positive card lists (that is, card registration data) in a central host.
There remain, however, the following two issues related to the open-loop systems utilizing validation terminals installed on the moving vehicles:                Issue 1. From a throughput perspective, the validation transaction time must not exceed 300-500 ms. However, validation terminals installed on the moving vehicles typically cannot get the approval response from the service provider's central host in less than 5-10 seconds.        Issue 2. The proper fare calculation at validation terminals requires card activity data that is not typically stored in regular open-loop cards.        
Some known solutions, such as that presented in U.S. Pat. No. 7,731,086, “System and method for mass transit merchant payment”, by Peter D. Saunders et al, initially charge the maximum fare without connecting to the central host for retrieving the data necessary to calculate the exact fare. The applicable discounts are accounted a day or two later, in a back-office clearing and settlement process, by adjusting the charged amount. This creates inconvenience. The card is temporally overcharged and in some situations this may cause service to be declined due to insufficient funds, even when sufficient funds are available.
Some known solutions allow access to the transit services before the response is received from the central host. In case of a later declined response, the card number is placed in a negative list but the last validated service will remain unpaid. Negative lists are actualized with a certain delay. This method presents the risk of counterfeit cards or cards with insufficient funds.
The known fare collection solutions implement methods of data downloading to the validation terminals via conventional data communication systems wherein the central host or a data concentrator maintains a separate two-way data transmission session with each validation terminal. Since the data package to be delivered to each terminal is the same, these solutions are technically redundant.
There are known solutions for broadcasting identical packages of data to many recipients simultaneously. These solutions have been used in teletext transmission since 1970. Satellite-based high-definition television broadcasting as well as satellite-based or terrestrial based XM radio broadcasting are good examples of digital broadcasting. One more example is U.S. Pat. No. 6,151,497, “Satellite based high bandwidth data broadcast” by David Moon Yee et al. Another example of satellite-based commercial data broadcasting is U.S. Pat. No. 7,562,049, “Payment system and method for data broadcasted from a remote location”, by Masayuki Habaguchi et al. This patent discloses a method of selling data segments (i.e. songs) broadcast to a remote location.
An example related to data multicasting to a group of mobile devices is U.S. patent application Ser. No. 10/635,037, “System and method for wireless multicast downloading”, by Paul Oommen et al. The multicasting methods may utilize conventional wireless cellular infrastructure. The set of terminals the data is multicast to may be determined dynamically.